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REMARKS 

This is a Response to the Office Action mailed August 3 1 , 2009, in which a three 
(3) month Shortened Statutory Period for Response has been set, due to expire November 30, 
2009. Thirty (30) claims, including eight (8) independent claims, were paid for in the 
application. No new matter has been added to the application. No fee for additional claims is 
due by way of this Response. The Director is authorized to charge any additional fees due by 
way of this Amendment, or credit any overpayment, to our Deposit Account No. 19-1090. 
Claims 1-26 are pending. 

35 U.S.C. § 102(b) Rejections 

Claims 1-26 were rejected under 35 U.S.C. § 102(b) as being anticipated by U.S. 
Patent No. 6,751,209 issued to Hamiti et al. (hereinafter "Hamiti"). 

Claims 1 and 12 

1) The office action alleges that Hamiti discloses "pre-configuring header 
compression lengths and length types required by the system" relying on Figure 5 and the 
passage at col. 7, lines 1-6 of Hamiti. 

The Applicants have realized that "the header size of the ROHC header- 
compressed packet from the upper layer is changeable in a wide range, thus a huge TFS must be 
employed to cover all the possible packet header sizes, which reduces the reliability of TFCI 
decoding and complicates the physical layer processing" (see page 6, third paragraph of the 
present application). Therefore, the PDU size adaptation unit 901 of the embodiments described 
in the present application "adapts the header-compressed packet or the compressed header or 
the data blocks containing the compressed header to several pre-configured size-fixed length", 
so as to ensure TFCI decoding and facilitate physical layer processing. See page 12, second 
paragraph of the present application, regarding act 1020 of Figure 10. 
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In contrast, Hamiti relates to performing header compression based on the fact 
that most of the fields in the network layer packet remain constant throughout a session. 

The part of Hamiti cited by the Office teaches that "Field 5 1 indicates the type T 

of the compressed packet If T=l the compressed header shall include the length octet and 

the bits 53 and the last octet 56 are used to indicate the length of the RTP payload . This length 
information is needed with bit streams where the packet length may vary, e.g. video bit-streams". 
(Emphasis added.) 

Clearly, this part of Hamiti only discloses that field 51 indicates the type of the 
compressed packet (whether it is a compressed packet that includes the length information (T=l) 
or not (T=0)), and the length information is for the RTP payload. Therefore, Hamiti does not 
disclose the " header compression lengths '" and " length types " as recited in the claims. 

Due to the above reasons, Hamiti does not disclose "pre-configuring header 
compression lengths and length types required by the system'" as recited in claims 1 and 12. 

2) The office action also alleges that Hamiti teaches "PDU-size adapting the 
plurality of different header compression lengths of the header-compressed RTP packets, so as to 
comply with said lengths and length types required by the system" relying on passages at col. 7, 
lines 1-6 and col. 9, lines 50-54 of Hamiti. 

As claimed, the "plurality of different header compression lengths of the header- 
compressed RTP packets" are PDU-size adapted to several pre-configured size-fixed length, so 
that the TFCI decoding can be ensured and that the physical layer processing can be facilitated 
by processing such header-compressed RTP packets of pre-configured size-fixed lengths. 

However, Hamiti, col. 9, lines 50-54 only discloses that two different SN-PDU 
formats are defined for acknowledged/unacknowledged data transfer. In particular, these two 
formats are used for correctly decompressing the identification data (i.e., RTP sequence number, 
RTP time stamp and IP identification, see fields 316, 317 and 335 of Figure 3) from the 
transferred compressed header in acknowledged and unacknowledged data transfer, respectively. 
Hamiti, col. 9, lines 40-42 and col. 9, line 59 to col. 10, line 22. 
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Since Hamiti defines the two SN-PDU formats based on their ACK mechanism, 
compressed packets are filled in a PDU format depending on whether they are of 
acknowledged/unacknowledged data transfer, which has nothing to do with size adapting the 
packets into different lengths as required by the system. In contrast, as claimed, the compressed 
header- packets are adapted to different sizes (i.e., lengths) as required by the system, so as to 
facilitate physical layer processing. 

Claims 13 and 21 

1) The office action alleges that Hamiti discloses "marking a compressed header 
and an RTP payload' relying on Figure 5 and the passage at col. 7, lines 8-9 of Hamiti. 

Although there is a marker bit in Hamiti, the passage at col. 5, lines 18-24 of 
Hamiti explains that "Field 3 14 includes a marker bit that is optionally used to mark important 
events in the packet stream, for instance, the beginning of a speech burst, or a last packet in a 
video frame." Therefore, the marker bit of Hamiti is not to mark a compressed header and an 
RTP payload as recited in the claims. In fact, Hamiti fails to teach or even suggest marking the 
compressed header and RTP payload. 

2) The office action alleges that Hamiti discloses " separating the compressed 
header from the RTP payload based on said marking, to respectively form PDCP layer PDUs 
before mapping them to different RLC entities " relying on the RTP part of Figure 3 and the 
passages at col. 4, lines 58-64 and col. 5, lines 20-22 of Hamiti. 

However, the passage at col. 4, lines 58-64 reads "[t]he access network SNDC 
function provides to the network layer a service for transferring a minimum amount of data 
between the SGSN and MS through different compression techniques. GPRS provides a 
procedure, which is implemented in connection with the service negotiation, for the MS and the 
SGSN to agree on the compression algorithm to be used in the session." The passage at col. 5, 
lines 20-22 reads "[i]f the marker bit 3 14 is used it needs to be transmitted in the compressed 
header. Field 316 indicating the sequence number and field 317 indicating the time stamp will 
change for all RTP Packets." These passages are silent regarding the above definition of the 
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claims. Moreover, Applicants' representative has noticed that the passage at col. 12, lines 17-19 
of Hamiti recites "[a]n SNDCP packet comprising the compressed header and the RTP payload 
is sent to the decompressor". (Emphasis added.) 

In view of the above, Hamiti does not teach or suggest the limitations recited in 
claim 13. Neither does Hamiti teach or suggest the limitations recited in claim 21 . 

Claims 20 and 22 

1) The office action alleges that Hamiti discloses "a compressed header of the 
header-compressed packet is separated from an RTP payload thereof at the transmitting end to 
form different PDCP layer PDUs that are transmitted on different RLC entities' 1 '' relying on 
Figure 1, element 16, and the passage at col. 8, lines 41-42 of Hamiti. 

As explained above, Hamiti docs not teach or suggest "a compressed header of 
the header-compressed packet is separated from an RTP payload thereof at the transmitting end 
to form different PDCP layer PDUs." In addition, Hamiti does not teach or suggest that the 
formed PDUs "are transmitted on different RLC entities" as recited by claims 20 and 22. 

2) The office action further alleges that Hamiti discloses " combining the extracted 
compressed header with the RTP payload" relying on the passages at col. 8, lines 63-67 and col. 
9, lines 1-14 of Hamiti. 

However, what is taught in those passages of Hamiti is "for packets that might 
disturb the compression, e.g. ones that arrive very late to the compressor and might therefore 
potentially disrupt the order of updating the compression information, a corrective action in the 
compressor will result." These teachings only relate to managing whether to recover or 
regenerate a late-arriving packet, while being totally silent with respect to the recited "combining 
the extracted compressed header with the RTP payload" of the claims. 
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Claims 23 and 26 

1) The office action alleges that Hamiti discloses "monitoring whether or not the 
bandwidth requirement of the RTP packet exceeds a predetermined value", relying on the 
passage at col. 7, lines 31-65 of Hamiti. 

However, that passage is directed to reconstructing a time-stamp, where the time- 
stamp constitutes the context data (see Hamiti, col. 7, lines 10-15, Figure 5), while the context 
data comprising information for relating the received compressed value to a corresponding 
compression sequence, the information being updated according to the received compressed 
values (see Hamiti, col, 3, lines 2-5). Obviously, the above description has nothing to do with 
"monitoring whether or not the bandwidth requirement of the RTP packet exceeds a 
predetermined value" as alleged in the office action. 

2) The office action further alleges that Hamiti discloses "if the bandwidth 
requirement of the RTP packet exceeds the predetermined value and there is an RTCP packet to 
be transmitted, bu ffering the RTCP packet" relying on passages at col. 7, lines 31-65 and col. 4, 
lines 64-66 of Hamiti. 

First, it seems that the Office considers "a number of header data fields that 
remain constant during the data transfer" of Hamiti as equivalent to the "RTCP packet" of the 
present claims. However, "RTCP is used for periodically transmitting such information as 
quality parameters of the media transmission" See, "BACKGROUND OF THE INVENTION, 
para. 2 of the present application (emphasis added). In contrast, "a number of header data fields 
that remain constant during the data transfer" of Hamiti refers to the header data fields that 
remain constant during a session. Hamiti, col. 5, line 1 to col. 6, line 4. Notably, none of which 
header data fields are used to periodically transmit such information as quality parameters of the 
media transmission, as the RTCP packet does. Therefore, "a number of header data fields that 
remain constant during the data transfer" of Hamiti is not the same as, or equivalent to, the 
recited "RTCP packet." 

Additionally, Hamiti does not even mention "buffering the RTCP packet." 
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3) Since Hamiti does not disclose the above elements of claims 23 and 26, Hamiti 
cannot disclose "continuously monitoring the bandwidth requirement of the RTP packet, and 
transmitting the RTCP packet when the bandwidth requirement is lower than the predetermined 
value". 

In light of the above, the pending independent claims, as well as the dependent 
claims, are not anticipated by Hamiti, and thus are patentable. 

Conclusion 

Applicants respectfully submit that the pending claims are in condition for 
allowance. Any remarks in support of patentability of one claim should not be imputed to any 
other claim, even if similar terminology is used. Any remarks referring to only a portion of a 
claim should not be understood to base patentability on that portion; rather, patentability must 
rest on each claim taken as a whole. A number of clarifying amendments have also been made 
to the above claim set. Applicants do not acquiesce to each of the Examiner's rejections and to 
each of the Examiner's assertions regarding what the cited references show or teach, even if not 
expressly discussed herein. Although changes to the claims have been made, no acquiescence or 
estoppel is or should be implied thereby; such amendments are made only to expedite 
prosecution of the present application and are without prejudice to the presentation or assertion, 
in the future, of claims relating to the same or similar subject matter. 



7 



Application No. 10/577,641 

Reply to Office Action dated August 31, 2009 

If the undersigned attorney has overlooked a relevant teaching in any of the 
references, the Examiner is requested to point out specifically where such teaching may be 
found. In light of the above amendments and remarks, Applicants respectfully submit that all 
pending claims are allowable. Applicants, therefore, respectfully request that the Examiner 
reconsider this application and timely allow all pending claims. The Examiner is encouraged to 
contact the undersigned by telephone to discuss the above and any other distinctions between the 
claims and the applied references, if desired. If the Examiner notes any informalities in the 
claims, the Examiner is encouraged to contact the undersigned by telephone to expediently 
correct such informalities. 

Respectfully submitted, 

SEED Intellectual Property Law Group pllc 

/Frank Abramonte/ 

Frank Abramonte 
Registration No. 38,066 

FXA:sc 

701 Fifth Avenue, Suite 5400 
Seattle, Washington 98104 
Phone: (206)622-4900 
Fax: (206) 682-6031 
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